test(plugin-calendar,plugin-gantt): the colorField ladder fixtures name their own writer (objectui#7828) - #7892

Fixes #7828

Ports objectui#7527's three harness guards (c2fc261f5) plus PR #7826's bound capture to the two sibling colorField ladder fixtures. Test fixtures only — no runtime code, no gate predicate, no gate scan population. packages/core/src/utils/record-color.ts is untouched: #7466 cleared the shared ladder of any role.

Why touch a file that is green

The exposure lever is two renders inside one it. RTL's auto-cleanup runs in afterEach, so across it blocks the previous writer is already unmounted; only inside one it do two components stay alive against one module global. The card checked mechanically that no it in either file renders twice today — which is why nothing is red.

So these fixtures are not failing. They are one edit away from failing, and that edit is "add a second assertion to one of those it blocks" — the ordinary way to extend a ladder fixture, what the timeline file's rung 2 already does, and precisely the edit that produced #7466. The guards are what make that next edit safe.

What changed

Four points, both files:

1. the readiness predicate identifies which render wrote — a title token the call owns, riding through titleField — instead of counting arity. lastEvents.length === rows.length cannot separate "the component I just mounted has painted" from "an earlier one painted again";
2. the helper returns the array the predicate accepted, not a second read of the module global taken after act has yielded on its way out of waitFor;
3. the render is torn down in a finally;
4. no renderer may be alive when one is mounted (a structural check at a synchronous point, not a timing one).

In the gantt file the two it blocks that mounted inline now go through the same helper. Guard 4 is only worth anything if every render in the file is accounted for — an inline render left mounted is exactly what it is meant to catch.

Evidence — outcome (b): the two siblings do NOT paint twice

Reported honestly, and stated plainly: no failure was reproducible on either file today.

A green loop is not evidence here and none is offered. #7466 paid for that reading — the broken timeline harness passed 32/32 on an idle box, the same 32/32 the fixed one gets. The lever is the metadata fetch, not machine load, so the lever was swept.

Instrument: the pre-port harness shape (module global, arity-only predicate, no unmount, re-read of the global) driving two renders inside one it — the #7466 exposure shape — with getObjectSchema held by 0/1/2/3/4/5/6/7/8/9/10/12/15/20/25/35/50 ms, three runs per hold, all three components in the same vitest runs:

The control is what makes those two zeroes readable at all: the instrument does fire, in this container, on this day, in those same runs — with the card's exact signature, the second render reading the first render's colour back out of the global (second=["#abc"] where ["#123456"] was authored). Note where it fires: every timeline failure sits at a hold of 1-9ms, and the first, coarser grid caught it at one hold out of eight. That is why the grid was refined instead of repeated — repetition at a hold outside the window is the 32/32 that taught #7466 nothing.

And the mechanism, measured the same way — writes into the module global after the readiness predicate went green, render left mounted exactly as the pre-port harness leaves it:

ObjectTimeline's data effect lists objectDef, so it paints once before the metadata lands and again after. Both siblings gate their record query on the settled object schema (objectui#6453 for the calendar, objectui#7225 ask 2 for the gantt, today the shared useSettledSchema), so their first paint arrives only after the metadata read — the measured paint time tracks the hold, 34ms/104ms for the calendar and 31ms/114ms for the gantt at +25/+100 — and no schema-triggered second paint follows.

So this PR does not claim the timeline's two-paint behaviour for either sibling; it was looked for, with a lit instrument, and it is not there. What is ported is the harness half, which does not depend on it — in the card's own words, a module global plus an arity-only predicate cannot say which component wrote, whatever the components do. Both file headers carry these numbers.

Changeset

Test-only, so the empty-frontmatter form is the expected pass. node scripts/check-changeset-presence.mjs, verbatim:

Compared the working tree with 83fe6e741 (merge-base with origin/main): 2 file(s) changed, 2 of them published source of a package the release covers, 0 of them a manifest whose published contract moved, 0 under a package changesets ignores, 1 changeset(s) added.
OK  2 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s): .changeset/7828-calendar-gantt-ladder-harness.md.
    Every one of them has an EMPTY frontmatter — declared as releasing nothing, which
    is the explicit exemption and a complete answer to this gate.

(The verdict line is prefixed with a green check in the real output; transcribed here as OK so the character survives.)

Verification

Re-run after the final commit, on the pushed SHA 2dc8ba4f8, with git diff HEAD empty:

• pnpm exec vitest run packages/plugin-calendar/ packages/plugin-gantt/ — 87 files / 634 tests passed
• pnpm --filter @object-ui/plugin-calendar --filter @object-ui/plugin-gantt run type-check — Done for both (tsc --noEmit && tsc -p tsconfig.test.json; --listFiles confirms both edited fixtures are in that program, so this is a real reading about them)
• pnpm --filter ... run lint for both packages — 0 errors (161 and 353 pre-existing warnings)
• check-changeset-presence, check-changeset-no-major, check-changeset-overwrite, check-control-bytes, check-vi-mock-specifiers, check-vi-mock-inherit, check-unreferenced-sources, check-lint-coverage — all exit 0
• check-governed-queue-guard --test on all three changed paths — NOT GOVERNED, 3 path(s) checked against 5 governed surface(s); none matched

Repo-wide pnpm lint (turbo, 46 packages) is left to CI; the two packages whose files changed were linted in full, and the config is not type-aware, so this change cannot move a judgement on a file it does not touch.

Generated by Claude Code